이 블로그 글을 읽고 내 상황에 맞춰 다시 써보았다. 직접 인용이 많이 포함되어있다.
2020-12-11
회사에 오래 다니지 않아 예전의 상황을 잘 아는 것은 아니지만 온전히 현 상황을 놓고 볼 때 이전보다 피쳐 개발을 빠르게 하고 있다는 것이 느껴진다. 그리 오래된 프로젝트가 아님에도 내 기준에 회사의 코드는 꽤나 복잡하다. 사소한 버그를 고치기 위해 몇 시간을 써야하는 경우가 한 두번 발생한게 아니니 비단 나의 주관만은 아닐 것이다. 왜 두 줄밖에 짜지 못했어? 라고 물어보면 정말 할 말이 많다.
그에 비해 리팩토링 작업은 빈약하다. 프로젝트의 이해도가 떨어지는 나와 다른 개발자 한분만이 다른 사람들의 코드를 조금씩 개선하고 있을 뿐이다. 솔직히 말해서 제품의 주력 기능과 관련있는 코드쪽은 마치 시한 폭탄같다 혹은 블로그 글을 인용하자면 마치 "비행기를 공중에 띄운 채로 만들고 있는 상황"이다. 내 눈에 이쪽은 그 누구도 리팩토링하는 것을 엄두를 못내고 있는 것처럼 보인다(다른 피쳐 개발에 치여 시간을 못내고 있는 걸 지도 모른다). 그러는 와중 우리보다 훨씬 강력한 경쟁사가 치고 들어오기 시작했고 프로젝트 매니저는 '현 상황에서 개발 퍼포먼스를 더 낼 수 있는 방법'을 위한 회의를 열었다. 그는 솔직하게 현 상황에 대해 얘기해 보라며 '다시 만들어야 한다'와 같은 의견도 솔직하게 내달라고 했다. 솔직히 그렇다고 말하고 싶었지만 이 대답은 근시안적으로 볼 때 회의를 연 목적에 정반대가 되는 대답이었기 때문에 그럴 수 없었다.
다시 본론으로 돌아가보자, 기술 부채란 무엇일까? 우리 회사 사이트의 위키에 기술 부채 항목을 열어보면 뭔가 구체적으로 문제가 되는 항목 몇 가지만이 나열돼 있는데, 기술 부채라기보다 사용자 관점에서만 바라본 회사 프로그램의 현재 문제점에 가깝다. 하지만 모두가 알 것이라 생각한다. 기술 부채란 마음으로 느껴지는 그런거다. "코드 스멜"이 많으면 기술 부채일까? 그것도 아니다. 내가 느끼는 "코드 스멜"이 다른 사람의 코딩 스타일일 수 있기 때문에 기술 부채의 객관적인 정의가 되기는 힘들다. 만약 순전히 코딩 스타일이 다르다고 그걸 기술 부채라 여긴다면 특정 코딩 스타일을 가진 개발자를 채용했을 때 그의 코드를 맨날 고치고 앉아있을 것이다. 코드를 작성할 때 무엇을 어떻게 하기위해 이렇게 했는지를 얘기했을 때 동료들이 납득한다면 충분히 [[좋은 코드]]일 것이다.
정녕 와닿는 기술 부채의 정의는 없는 것일까. 블로그 글의 저자는 검색 끝에 Ward Cunningham이라는 소프트웨어 공학자의 짧은 영상을 보고 수긍하기에 이르렀는데 이 사람은 무려 기술 부채라는 단어를 만든 사람이다. 기술 부채란...
"프로그램을 장기간 개발하면서 기능을 추가하기만 하고 추가한 기능의 이해를 반영하도록 재구성하지 않는다면, 결국 프로그램에 '이해'란 남지 않게 되며 뭘 하든 점점 더 오래 걸릴 수 밖에 없다" -- Ward Cunningham
난 이 사람의 의견에 공감하지 않을 수가 없다. 프로젝트 전반의 구조, 기능 내 어떤 위치에 있는지 생각치 않고 기능을 계속해서 추가하기만 하면 그게 바로 기술 부채인 것이다. 특히 배포 주기가 짧은 프로젝트일수록 부채가 빨리 쌓일 것이다. 그리고 이런 부채는 얼마안가 실제 비용이 된다. 비용 계산은 간단하다. 개발자들에게 돈을 주면서 기능 개발을 늦추고 리팩토링을 하면서 주석, 문서등을 만들게 하던가, 뭔가 이해할 때 까지 멍하니 코드만 보고있도록 두던가. 멍하니 보고 있는 시간은 갈수록 늘어날 것이다. 재능이 있는 사람들은 모두 이 짓거리를 몇번 하다가 퇴사하고 말것이고, 회사는 점점 올라가는 퇴사율로 그 비용을 지불하게될 것이다.
그럼 어떻게 해야할까? 어떤 기업은 이를 해결해보고자 위키를 사용한다. 그러나 여기서 마저 똑같은 문제가 발생한다. 쌓여가는 위키를 대체 누가 정리할까? 요즘은 좀 나아진 편이지만 당장 우리 회사 위키만 봐도 개발에 크게 도움되는 문서를 찾기 쉽지 않다. 혹은 있더라도 검색 자체가 어렵다. 블로그 글의 저자는 대체로 기업 위키는 엉망이며 기업은 위키가 필요없다고 주장하는데, 그 이유인 즉슨 우리가 흔히 아는 위키피디아(나무위키?)같은 성공적인(?) 위키는 수 많은 사람들이 편집을 하는 반면, 기업에선 절대 그 정도의 시간을 위키를 관리하는데 쓰지 않기 때문이다. 주변 사람들한테도 몇번 들은 말이지만 회의를 아무리 잡고 위키에 뭔가를 열심히 기록해봤자 그걸 기억하는 사람은 몇 되지 않는다. 그러고 똑같은 회의를 계속 하겠지.
기술 부채를 Cunningham의 정의대로 이해하는 팀장 혹은 매니저라면 필요에 의해 시간을 들여 크게 리팩토링하는 것이 매우 당연하다고 생각할 것이다. 기업의 구성원이 많이 바뀌었거나 무분별한 기능 추가(Feature Creep)가 계속 되어서 미래를 종잡을 수 없는 경우엔 리팩토링보다는 아예 처음부터 다시 하는것이 맞는 결정일 수도 있다. 팀을 꾸리고 처음부터 프로젝트를 다시 만든다면 집단 이해도(Collective Understanding)는 올라갈 것이고 이는 기술부채가 쌓이는 속도를 늦출 것이다. 그러나 이것도 팀을 이끌고 갈만한 역량이 있는 사람이 한 사람이라도 있어야 가능하다. 처음부터 다시 하더라도 똑같은 팀이 동일한 방식으로 개발을 한다면 결과는 뻔하다. 코드 베이스를 살펴보면 개개인의 역량보다 팀의 성격이 더 눈에 띄는데, 이는 정리되지 않은 코드가 팀 업무 방식의 문제일지도 모른다는 점을 귀띔한다. 프로젝트를 올바른 방향으로 잘 이끌어 줄 특출난 리더가 없다면 후일을 생각하여 가능한 빠르게 프로젝트 진행방향이나 관리 방법에 팀 전원이 관심을 가지도록 해야한다.
여하튼 급하게 작성된 코드베이스를 가지고 개발하는 사람들에게 개발 퍼포먼스를 기대하는 것은 바보같은 짓이다. 만약 그런식으로 짜여진 코드를 만든 사람이 퇴사하거나 팀에 더이상 없다면 그때는 이미 '기술 부채의 풍선이 터지고'만 것이고 회사는 득될 것없는 자산을 갖게 된 것이다👏. 결과를 겸허히 받아들이자. 아니면 현재 상황을 직시하고 몇 가지 원칙을 서로 지키기로 약속한뒤 엔트로피를 거스르거나, '기술 신용'을 쌓을 수도 있다. 한가지 분명한점은 무분별하게 '기능 추가'만을 계속 좇는 짓을 그만둬야 할 때라는 것.